In distributed microprocessing systems, typically each processor and the devices associated with that processor are connected to a bus. Multiple processors and devices can be connected to a single bus. Processors and devices can transmit information across the bus. In many systems today, to allow more total devices, multiple busses are connected by bus bridges that allow devices on one bus to access devices on another bus. Some bus bridges are unidirectional, meaning information can only flow in one direction, while other bus bridges are bi-directional, meaning information can flow in both directions. A bus bridge will forward read or write transaction requests that originate on one bus to another bus in the system. Typically, the first device to request access to the bus is granted access to the bus for a predetermined period of time. Most bridges use some form of xe2x80x9cround-robinxe2x80x9d rules to control traffic on the bus, wherein the most recent device that has been granted access to the bridge to transmit information will become last in line to gain access again, and the least recent device that has a request pending will be the next to be granted access to the bridge. This logic is designed to ensure that each device has equal access to the bus.
Bus to bus bridges forward standard transactions like memory reads, memory writes, I/O reads and I/O writes from a device connected to one bus on the bridge to a device on another bus on the bridge. Some bridges also forward a type of transaction called a xe2x80x9cmessagexe2x80x9d. The act of forwarding a message from one side of the bridge to the other is called xe2x80x9cmessage passingxe2x80x9d. Messages are typically stored in a message container inside the bridge. When a message is being forwarded across a bridge, it typically generates an interrupt to let the CPU on the receiving end know that the message has arrived. The receiving CPU typically clears the interrupt by zeroing out some or all of the message after the message has been read. In some systems, the receiving CPU will send a message to the sending CPU to indicate that the message has been received. In a system in which the receiving CPU does not send such a message, the sending CPU will typically poll the message container to determine if the message has been zeroed out so it can determine when the message has been received.
Messages are typically sent for the purpose of informing a receiving CPU that a certain block of data has been read or written to memory. In order to minimize latency in the system, bridges typically xe2x80x9cpostxe2x80x9d writes in the bridge. This means that the bridge accepts write data into the bridge to the extent of its buffering capability, thus completing the write transaction on the sending bus as soon as possible. The bridge then begins to write the data in its buffers onto the local memory of the appropriate receiving bus. However, the amount of time this can take may vary because the bridge may not gain ownership of the receiving bus right away, and because the receiving bus may force the bridge to break up the write into multiple transactions which themselves may be interleaved with transactions of other devices. The consequence of this is that the write transaction is complete on the sending bus for an indeterminate amount of time before it is actually completed on the receiving bus. Therefore, if the sending CPU sends a message that it has completed a write function, some portions of the write transaction may still be in the bus bridge waiting to complete the entire write transaction. This could cause incorrect data to be received if the message that the write transaction was completed is received by the receiving CPU before all the blocks of the write transaction are received into memory on the bus on the destination side of the bridge. To overcome this problem, the messages must follow the same set of ordering rules that are followed by normal write transactions being sent across the bridge.
One solution to this problem has been to put the messages themselves in the same queue as the transactions. A bridge typically has one or more write buffers that receive write blocks. Each buffer can accommodate a block of the size that can be managed easily by the bridge. If a message is put into the write queue with the write transaction, after the last block of the write data, then the message will be placed into the queue behind the transaction, and into a subsequent write buffer. This ensures the message will not be sent until the last block of the write is sent. When the message gets to the top of the queue, it is put into the message container, rather than being written into the destination bus memory, and the interrupt is generated. However, even if a particular block of data is smaller than the buffer size, it is typically put into a buffer by itself, and no additional data is put into that particular buffer. This is because managing transactions of varying sizes in a buffer is difficult for a bridge, and so bridges are usually not configured that way. A message is typically of a small size. By putting a message into the write queue, it will occupy an entire buffer that could be used for subsequent write transactions, instead. This reduces system performance.
Accordingly, a continuing search has been directed to the development of systems and methods which can send a message to the message container without having to utilize the write queue, while still maintaining ordering of the data in the write queue and the subsequent message.
The present invention, accordingly, provides a system and method that involves putting the message directly into the message container without having to utilize the write queue, and ensuring the message is sent in order by setting a flag in the bridge logic that keeps track of which buffers in the queue were pending when the message was received, and not sending the message until all those buffers have been emptied.
The invention comprises a method and apparatus for delivering an incoming message in a system comprising a bus bridge and at least two buses connected to the bus bridge. A message from a device on a first bus on the bus bridge is transmitted into a message container on the bus bridge. The bus bridge tracks all data write functions in buffers on the bus bridge when the message is received in the message container. The system sets a flag that blocks generation of an interrupt indicating to a receiving device on a second bus on the bus bridge that the message is in the message container. The flag being set also prevents the receiving device on the second bus from accessing the message in the message container. When all data write functions in the bus bridge buffer being tracked have been written, the system sends a signal that clears the flag so the receiving device on the second bus can read the message in the message container.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.